stream: fix pipeline function tail deadlock - #65559

Review requested:

• @nodejs/streams

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.07%. Comparing base (7b6b21a) to head (90231b2).
⚠️ Report is 61 commits behind head on main.

@@            Coverage Diff             @@
##             main   #65559      +/-   ##
==========================================
+ Coverage   90.05%   90.07%   +0.01%     
==========================================
  Files         751      751              
  Lines      254420   254430      +10     
  Branches    47975    47981       +6     
==========================================
+ Hits       229121   229169      +48     
+ Misses      16483    16437      -46     
- Partials     8816     8824       +8     

CI: https://ci.nodejs.org/job/node-test-pull-request/76577/

It looks like the CI run failed, but I don't have access to the Jenkins failure details. Could someone with access please check which test failed and whether it is related to this change? Thanks!

CI: https://ci.nodejs.org/job/node-test-pull-request/76666/

CI: https://ci.nodejs.org/job/node-test-pull-request/76679/

Thanks for the clarification. I understand the concern that automatically calling .resume() on the returned proxy could consume and discard data.

I have one question about the promises variant. When the final function returns an AsyncIterable, pipelineImpl() creates a PassThrough proxy so that the callback-based pipeline() can return it and allow further piping. However, stream/promises.pipeline() only exposes the Promise, so the caller cannot directly consume that proxy.

The current documentation also lists AsyncIterable as a valid return value for a function used as the destination.

In this case, would the preferred behavior be to keep the current semantics and treat this as expected behavior, or should the promises variant reject or document an AsyncIterable-returning destination differently?

I'd be happy to adjust the PR accordingly. Thanks!